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Method and system for notifying customers of transaction opportunities 



(57) A standalone notification system, including a 
notification server which generates electronic messag- 
es to registered customers upon their request or upon 
a host business request. The customer provides the 
system with his/her messaging identification ("ID"), e.g. 
e-mail address, GSM (global system for mobile commu- 
nications) or other mobile phone numbers that are able 



to accept, e^, short message service ("SMS") messag- 
es, facsimile number, and/or telephone number. Cus- 
tomers can register with the host notification server with- 
out having any relationship, banking or othenwise, with 
the host. Customers can choose between different no- 
tification channels such as e-mail, SMS message, fax 
or pager. 
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Description 

CROSS-REFERENCE TO RELATED APPLICATiONS 

s [0001] The current application claims priority to provisional application number 60/1 97,773 filed April 14, 2000 enti- 
tled. "METHOD AND SYSTEM FOR NOTIFYING CUSTOMERS OF TRANSACTION OPPORTUNITIES," which Is 
incorporated herein by reference in its entirety. 

BACKGROUND OF THE INVENTION 

10 

Field of the Invention 

[0002] This invention relates to financial transaction notification systems and methods, generally. Particularly, this 
Invention relates to systems and methods for collecting, monitoring, and comparing data to customer requests. 

15 

Description of Related Art 

[0003] Prior to the current invention, available event notification systems included, for example, local desktop noti- 
fication systems, such as e-mail alerts or instant messaging alerts which alert a user through a visual or audio signal 
20 that a new e-mail or instant message has arrived and is available for retrieval within the users local computer network. 
These alerts merely indicate that a message is available for viewing, the alerts do not provide the substance of the 
message. 

[0004] Other event notification systems alert a user via, for example, an e-mail message, of the availability of certain 
infomnation, solicited or unsolicited, on the Intemet or World Wide Web through a specified Web site or universal 

25 resource locator ("URL"). An unsolicited notification includes, for example, the availability of an electronic greeting card 
( e.g. , www.bluemountain.com). A solicited notification provides notification of the availability of infonnation that was 
specifically requested by the user. For example, atwww.realtor.com, a registered user can request notification of homes 
for sale according to pre-defined user parameters, e.g., location, price, number of bedrooms. When homes meeting 
the registered user's parameters are listed on the www.realtor.com Web site, the Web site sends an e-mail to the 

30 registered user indicating that there are homes available for sale fitting the user's parameters and providing the link to 
the Web site In the e-mali. These types of notification systems are limited to one method of notification, e-mail. Further, 
the notification system is not linked to any other type of user information, such as user financial infonnation, e.g., bank 
accounts, credit accounts, investment accounts, that is constantly variable due to the actions of the user, Le^ the 
actions of the user do not result In a triggering of the alert. 

35 [0005] Finally, there are notification systems available wherein a user's local computer Is equipped with a data filter 
that receives and searches incoming data messages, e.g., e-mail messages. Intended for the user, for predetemnlned 
event infonnation. When the data filter identifies the predetemnlned event infonnation, a local event indicator, e.g., 
audio and/or visual, is presented through the user's local computer indicating that a previously specified event has 
occurred. The user then has a specified amount of time, e^, 10 seconds, to acknowledge the local event indicator 

40 by, for example, clicking on the provided visual alert, e^, icon. If the user does not acknowledge the local event 
indicator within the specified amount of time, the user's computer establishes a connection with a server in order to 
remotely notify the user of the event through a notification method of the user's choice, such as, pager, telephone, or 
personal digital assistant ("PDA"). This notification system is limited to searching and retrieving local event infonnation 
from user-intended messages, e.g., Web pages pushed to a users e-mail address. Further, the local events, though 

45 pre-defined and requested, are not triggered by user actions, such as financial transactions. 

BRIEF SUMMARY OF THE INVENTION 

[0006] Consequently, there Is a need in the art for a notification system that Is directly linked to the actions of the 
50 user, in addition to the pre-defined parameters selected by the user, wherein such a system collects data independent 
of any electronic address of the user, Le., Infonnation searched for the requested alert Is not limited to messages 
directed to the user. Further, there is a need for a notification system wherein the requested alerts are triggered based 
on the values of private customer-specific financial Infonnation , such as bank account, credit card, or brokerage portfolio 
infonnation. 

55 [0007] Various embodiments of the present Invention comprise a standalone notification system, Including a notifi- 
cation server which generates electronic messages to registered customers upon their request or upon a host business 
request. A customer provides the system with his/her messaging Identification ("ID"), e.g. e-mail address, GSM (global 
system for mobile communications) or other mobile phone numbers that are able to accept, e^, short message service 
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(-SMS") messages, facsimile number, and/or telephone number. Customers can register with *e hMt notification 
ierver without havi;g any relationship, banking or otherwise, with the host. Customers can choose between drfferent 
notification channels such as e-mail, SMS message, fax or pager. n„re«nnoi 
m008] Further embodiments of the present invention comprise a notification system. wh«h allows Jost Pereonn^^^ 
such as customer service representatives ("CSR"). to create and maintain customer requests °" behalf of a^^^^^^^^^ 
[0009] The design of the notification system is geared toward scalability and perfomiance. The nofficat on system 
ensuresascalable architecture by usingastateless Web site and distributed architecture. The use ofastateless Web 

site results in increased available memory. 



BRIEF DESCRIPTION OF THE DRAWINGS 



[0010] 



Figure 1 is a schematic view of a nofification system according to an embodiment of the present invention; 
Flqure 2 is a schematic view of a Web page according to an embodiment of the present Invention; 
Figure 3 is a schematic view of Web page according to an embodiment of the present invention; 
Figure 4 is a schematic view of a Web page according to an embodiment of the present invention; 
Figure 5 is a schematic view of a Web page according to an embodiment of the preserit invention; 
Figures 6(a) and 6(b) are schematic views of a Web page according to an embodiment of the present invention. 
Figure 7 is a schematic view of a Web page according to an embodiment of the present invention; 
Figure 8 is a schematic view of a Web page according to an embodiment of the present invention; 
Figure 9 is a schematic view of a Web page according to an embodiment of the present invention; 
Figure 10 is a schematic view of a Web page according to an embodiment of the presen invention; 
Figure 1 1 is a schematic view of a Web page according to an embodiment of the present Invention; 
Figure 12 is a schematic view of a Web page according to an embodiment of the present invention; and 
Figure 1 3 is a flowchart illustrating a typical process flow when using a notification system according to an em- 
bodiment of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

room The notification system embodied by the present invention is capable of multiple avenues of access to and 
rom multiple parties. Further, the notification system utilizes multiple databases which are mfom^at^nja th^^ 
rZipTe parties and/or via other servers and/or back office host systems, such as readable files which are updated by 

runninq an appropriate executable program. 

Soi2] In an embodiment of the present invention, ail live financial inf omnation comes from °; "'"J^^^ 

Urs operated by the host financial institution. The information provided by these hos s .^^^ 

and the alert message generators included in the notification system in the fomi of a "host handoff (See FIG. 1). 

S file represents a data dump from the host database of all infomiation relevant to subscrrt^eis on the notrf^:a ion 

sySem These host handoff flies may be presented periodically (e^. once a day) or they can be represented as a live 

real-time connection between the back office host processor(s) and the notification system. 

po Sr in at least one embodiment of the present invention, a preferred medium or fac. itating a ' of ^a customer 

configuration interactions described below Is a public access network, such as the Intemet or Worid Wide ^eb Jue 

to such a networl^s far-reaching, efficient and expeditious characteristics tor <l«ta;ransmjssion ar^d prese^^^^^^^^^ 

oarticulariv effective method of displaying and generating data and infomiatlon Is through the use of Web sites and/or 

Cp?g2^.Wh eThespeclficschema^ll^^^^^^^^ 

and syr^hesizing data within the databases themselves, the requests for data which are ^J^^'^J^^^^^^^ 

or CSRs are made through a more user-friendly and recognizable fomiat such as a graphical f '^^Jf^/ < ^^^^^^ 

mU] inatieastoneembodimentofthepresentinvention.multipleWebsnesareprovidedtofacilitatedatacollect.^ 

Lnd p esentation. The following, which are In no way intended to be limrting. represent Web sites and Web pages us^^^^ 
?napJ?erred embodiment of thepresentinvention:non-member customer ("NMC-)preferencesite;m^^^ 
"McTpre^^^^^^^^^ (e.g.. CITIDIRECT® customer preference sub applications ("MiniApps") and T-^nsaction exec- 
utoS)! CSR preference site; product intomiation. rates and host messages maintenance site; notification reports site, 
system maintenance site; and database access security site. ,h«r«aft«r "ho«5t"^ 

[001 5] in an embodiment of the present invention wherein a sponsoring financial institution or host (^ereatte host ) 
maintains the notifteation system, the host establishes a central Web site (e.g.. homepage) as an advertising and 
expSrorymBchanismaswellastheconduitthroughwhichMCs.NM 

Togin web pages. The tomiat of the Web sites and Web pages may be HTML, XML. or the hke^ DaP«"'i"9;";^^'^.J 
type of customer is attempting to gain access, the customer selects the appropriate link, which links ttiem to a login 
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Web page. Once presented with the selected Web page, the user may be further prompted to select between a "first- 
time user" and a "repeat user" login link. The difference between these two login links being the amount of infomnation 
which needs to be entered prior to granting the user access to the preference sites. 

[0016] Referring to FIG. 1 , the notification system 10 is comprised of a system of servers and databases which are 
5 accessed via the Internet, through various Web sites, such as a CITIALERTm non-member Web site 12 and/or a 
CITIDIRECT® member Web site 14, and a CITIALERT" maintenance Web site 110. Since the present invention, 
though affiliated with one or more hosts, does not require that the customers accessing or using the notification system 
actually have a financial relationship with any one of the controlling hosts, Web site 12 may be used by all customers, 
including non-member customer ("NMC") (e.g., customers who do not have a relationship with the affiliated host or 
10 hosts) while Web site 14 provides access to the notification system 10 to member customers ("MC") only. Web site 
110 is used by employees of the hosting financial institution to configure the alert system. 

[0017] Web sites 12, 14 and 110 feed infomiation, directly and Indirectly, to a number of sources. The Web sites 12 
and 14 are sources of configuration Infomiation related to the specific configuration parameters for each customer 
(both member and non-member users). The Web site 110 feeds additional configuration infomiation into the system. 

15 This Web site is only useable by host employees, and provides configuration information about the nature of the noti- 
fications; the text of the notifications; the manner of notification (email, SMS, etc.); and similar system wide configuration 
information. As discussed below, the invention also contemplates accessing external sources of information. One or 
more back office host processors 18 provide host handoff files to a host handoff files database 16 which include infor- 
mation that feeds into the customer preference database 24, the alert message text database 26, and the rates and 

20 infomiation database 30; and which, in some cases, are processed directly by the alert message generators 32. The 
infomriation provided by MCs and NMCs to Web sites 12 and 14 is fed into a database containing customer preferences 
24. The infomiation provided by the host's maintenance personnel to Web site 110 is fed into the same database 
containing customer preferences 24, as well as the alert message text database 26 and, potentially, the rates and 
infomiation database 30. The host-handoff files 16 are fed to all of these databases. Finally, in an embodiment of the 

25 present invention, the system uses externally generated data from external sources 28. These externally generated 
sources include Internet based sources, contracted sources via private lines or any other available sources. They feed 
information into the rates and infomiation database 30. The rates database contains infonnation including, for example, 
interest rates and fees on loans and credit cards, interest rates on deposit accounts, foreign exchange rates, etc. The 
infomiation database contains infomiation including, for example, product information, corporate news, new products 

30 or services, etc. 

[001 8] Given the three databases, customer preference 24, alert message 26, and rates and information 30; as well 
as the Information in the host handoff files database 16, alert message generators 32 access the information therein, 
to form a rates and infomiation alert message generator 34 and a host alert message generator 36. These alert message 
generators 32, generate the messages requested by the customers, which are stored in an alert message text database 

35 26 prior to being sent to a customer selected alert message gateway 40. As discussed below, these gateways may 
include but are not limited to e-mail 42, HTML (hypertext maric-up language) 44, pager 46, GSR call 48, mobile phone 
text messaging, Global System for Mobile Communications Sen/ice ("GSM") 50, and XML (extensible mari<-up 
language) 52, facsimile 54, and short message service ("SMS") 54. Through these alert message gateways 40, re- 
quested infomiation Is transmitted to the customer 58. 

40 [0019] In embodiments of the present Invention, multiple servers may be grouped according to the particular data- 
bases into which they are feeding data and information. While not explicitly depicted in the Figures, these servers or 
feeders are executables that are run through, for example, the system maintenance site. In order to continually update 
the databases within the notification system. For example, a customer profile server and a rates server both update 
the customer preference database 24. Similariy, the same rates server and a host handoff server update the host 

45 handoff files database 16. While not explicitly depicted in the Figures, the customer profile, rates, and host handoff 
servers are executables that are launched, for example, through the system maintenance sen/er/site 110. By way of 
example, prompted by the system maintenance server/site 110, in a specific embodiment of the present Invention, the 
servers read selected Infomiation from the up-to-date host handoff files, format the selected infomiation according to 
a command program and update the aforementioned databases, respectively Further in this specific embodiment, the 

so customer profile server's functionality is to keep up to date customer profile and customer relationship data. As will be 
discussed further later in this disclosure, the customer profile server updates only host customer records, such that 
only MO and not NMC notification set-ups are affected by this sen/er. The host handoff and rate servers functionalities 
are to import host generated events and to keep the rate related information up to date, respectively. 
[0020] The alert message generators 32 contemplated by at least one embodiment of the present Invention Include. 

55 a rates and infonnation alert message generator 34 and a host alert message generator 36. Message generators are 
designed to analyze the customer's preferences against current rates, product infomiation and host handoff data and 
create entries within the alert message text database 26. 

[0021 ] The rates and infonnation message generator(s) 34 is an executable which has direct access to the customer 
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preference database 24, to rates and information database 30 and to alert message text database 26 through database 

access security server. These executables populate the alert message text database 26 with notification requests 
based on customer preference specification and rates and info content. Each request record indicates the customers 
pref en'ed notification channel i.e. , alert message gateway. The message generators create the actual message phrases 

5 taking into consideration the type of transaction they are reporting on. 

[0022] The host alert message generator(s) 36 is an executable which has direct access to the customer preference 
database 24, to host handoff files database 16 and to alert message text database 26 through the database access 
security server. These executables populate the alert message text database 26 with notification requests based on 
customer preference specification and host handoff results. Each request record Indicates the customer's preferred 

10 notification channel. The message generators create the actual message phrases taking into consideration the type 
of transaction they are reporting on. The alert message gateways 40 are executables which extract the content from 
the alert message text database 26 based on the customer's prefen-ed notification channel and forward them to the 
corresponding gateway. FonA^arded messages are moved from a "work" table to an "audit" table within the same da- 
tabase. Specific alert message gateway agents will be written for each notification channel such as the FAX or the 

15 SMTP (simple mail transfer protocol) mail. In preferred embodiments of the present invention, a web-based product 
infomnation, rates and host messages maintenance site is provided to update Individual rates records, infomriation 
records, host product records, and to report on statistical usage of the product database. This site Is also used to enter 
the specific response messages sent to the customer for each event. 

[0023] In preferred embodiments of the present invention, a web-based reports server/site 100 Is used to generate 
20 M IS (management infonnation system) and marketing reports on the customer preference database 24 and alert mes- 
sage text database'26. The web-based system maintenance server site 110 is used to backup, archive, restore and 
report on statistical usage of all databases within the notification system 10. This system maintenance server/site 110, 
in addition to the configuration operations discussed above, is also used to launch and control different server execut- 
ables and different alert message generators 32. Finally, a web-based database access security server/site 120 Is 
25 used to control access to databases and servers within the notification system 10. This database access security 
server/site 120 gives a requesting server the proper database connection string, database login ID. and PASSWORD. 
The database access security server/site 120 has administrator privileges over all the databases. This server/site 120 
solves the problem of hard coding the database login IDs into the operating system registry. 
[0024] Referring to FIG. 2, MCs, NMCs, and CSRs may enter information through Web site 12. In particular, Web 
30 site 1 2 prompts MCs to login by clicking on a first link 1 1 , Web site 1 2 prompts NMCs to login by clicking on a second 
link 13 and Web site 12 prompts CSRs to login by clicking on a third link 15. Referring to FIG. 3, by clicking on the first 
link 11 , an MC is linked to the login Web page 17 for MCs, where the MC is directed to a first-time customer login link 
19 and a repeat customer login link 21. Referring to FIG. 4, selection of the repeat customer login link 21, results In 
Web page 23. Web page 23 prompts the MC for an ID name 25 and a PASSWORD 27. MCs ID name 25 and PASS- 
ES WORD 27 were established during a first-time login sequence, discussed below. 

[0025] Again, refemng to FIG. 3, an MC who Is a first-time MC, selects first-time customer login link 19. Referring to 
FIG. 5, selection of link 19 results in Web page 29 which prompts the first-time MC for various information, including, 
but not limited to, customer's LAST NAME 31 , customer's ACCOUNT NUMBER 33 (e.g., checking, savings with the 
host), personal identification number ("PIN") 35, customer selected ID name 37, customer selected PASSWORD 39, 
40 a repeat of the PASSWORD for verification 41 , and customer's E-MAIL ADDRESS 43. Additionally, In an alternative 
embodiment discussed further below, the first-time customer login page also requests payment information (not shown). 
At least one embodiment of the present Invention contemplates that a MC will have access to more types of notification 
requests than a NMC, due to the pre-established relationship with the host. As a result of this relationship, the MCs 
private financial information may be utilized in fulfilling a notification request. As such, at least one alternative embod- 
45 iment requires a P IN previously generated by the host for the MC, which adds a level of protection to the private financial 
infonnation (e.g., account numbers). 

[0026] Further alternative embodiments require that the MC pay a host-detemnined fee depending on various factors, 
such as the number of notification requests, the type of notification requests, and/or the MCs cun'ent financial rela- 
tionship with the host. In a particular alternate embodiment, the host requires a minimum cumulative balance of, for 

50 example, $1 0,000.00, including all of the MCs accounts with the host in order to avoid paying a fee for the notification 
service. In the case where the MCs balance is less than $10,000.00, the host charges the MC a flat monthly fee for 
using the notification service. These charges are assessed to, for example, the MCs credit card, wherein the MC 
provides credit card infomaation during the registration process (FIG. 5). One skilled in the art recognizes that alternative 
fee an^angements fall within the scope of this Invention. 

55 [0027] Referring to FIG. 6(a), upon successful login by an MC, the MC is linked to MC preference site 70 which 
utilizes a MinlApp and Transaction Executors. Further, fill-in fomis, similar to those used in, for example, the CITIDI- 
RECT® home banking system are used to collect MC data such as content to be notified on 72, prefen-ed channel of 
contact 74, and a prefen-ed time for notification 76. By way of example, the content to be notified on may Include, but 
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is not limited to Information relating to the MCs checking, savings and portfolio values, interest rates, stock quotes, 
credit specials (e.g., special loans, low credit card rates) and other financial specials offered by the host. Specific 
account-notifications can include, but are not limited to, past-due-date reminders, overdrafts, credit limits, specific credit 
charges (e.g. , single amount charges, location charges), credit fraud warnings (e.g. , based on unfamiliar pattern of 

5 charges, location of charges, amount of charges) direct deposits (e.g. , of salary, dividend, etc.), balance, credit card 
due dates, automatic bill payments, check clearing alert and ATM withdrawals. The preferred channel of contact may 
be selected from e-mail, HTML, pager, CSR, mobile phone text messaging, ex[., GSM, XML, facsimile, and SMS. The 
MC may request to be notified at specific times such as Instantaneously (e.g. , as soon as technologically possible 
when the requested event occurs), hourly, daily, weekly, or monthly. In alternative embodiments, the MC is able to 

10 select different notification times for different events. After making general notification selections via the MC preference 
site 70, the MC is linked to other Web pages (not shown) via the "CONTINUE" icon where they are able to provide 
more specific request infomnation (e.g. phone #, fax #, requested interest rate, requested account balance Infomfiation, 
etc.). The Transaction Executors have direct access to the internal databases and servers of the host (e.g. CITIGOLD® 
server), subject of course to Database Access Security server restrictions (discussed below). MCs have more options 

15 to select from, which are not available to NMCs, through MC preference site 70. Further, the MC preference site 70 is 
capable of generating reports 78. 

[0028] Referring to FIG. 6(b), in an embodiment of the present invention, when the MC clicks on the "CREATE 
REPORT' link 78, the MC is directed to a separate "Report Parameters" Web page 200 for defining report parameters. 
The "Report Parameters" Web page 200 facilitates user-defined reports 205, where the MC has the ability to define 

20 what type of report the MC would like to have created from the infomriation contained in the notification system, as well 
as predetennined parameter reports 210. Predetemiined parameter reports 210 Include, for example, today, daily, 
weekly, monthly notification reports which list all notifications sent during the current day for today and the immediate 
preceding specified time frame e.g. , preceding day, preceding week, preceding month for daily, weekly, and monthly 
notification reports. Further, the predetermined parameter reports 21 0 show all methods by which the notifications were 

25 sent as well as a summary of the notification, e.g. , "$1,000 deposited Into account no. XYZ on MM/DD/YY," User- 
defined reports 205 allow the user to specify parameters used to create the report from specific dates and date ranges 
to specific accounts, to specific notification methods through which the specified notifications were sent. Once the MC 
selects their desired report parameters or predetennined parameter report, clicking on the "GENERATE REPORT" 
button 215 results in a report which includes the desired parameters. 

30 [0029] In an embodiment where a NMC enters the initial Web site 12, the NMC selects link 13 which, referring to 
FIG. 7, links the NMC to the NMC login Web page 45 which prompts the NMC to select between a first time customer 
login link 47 and a repeat customer login link 49. Additionally, Web page 45 may offer a link to the host's homepage 
51, in order to familiarize the NMC with the other services offered by the host, with a reminder that the notification 
system offers a wider range of services to MCs. Selection of repeat customer login link 49 links the NMC to the repeat 

35 customer login Web page 53, as show In FIG. 8, where the NMC is prompted to enter previously selected ID name 55 
and PASSWORD 57. 

[0030] Altematively. referring to FIG. 9, when the NMC selects the first-time customer login link 47, the NMC is linked 
to the first-time customer login Web page 59, where the NMC is prompted to enter some or all of the following infomnation 
including customer's FULL NAME 61 , customer's selected ID Name 63, customer's selected PASSWORD 65, repeat 

40 of PASSWORD for verification 67, and customer's E-MAIL ADDRESS 69. Refemng to FIG. 10, upon successful login, 
the NMC is linked to a stateless NMC preference site 80 which uses an HTML fonn to collect customer data such as 
content to be notified on 82, preferred channel of contact 84, and preferred time for notification 86. By way of example, 
the content to be notified on may Include, but Is not limited to information relating to interest rates, mortgage rates, 
stock quotes, credit specials (e.g., special loans, low credit card rates) and other financial specials offered by the host. 

45 The preferred channels of contact 84 and the preferred times for notification 86 are similar to those listed with reference 
to 74 and 76. After making general notification selections via the NMC preference site 80, the NMC is linked to other 
Web pages (not shown) via the "CONTINUE" icon where they are able to provide more specific request Infonnation 
(e.g. phone #, fax #, requested Interest rate). This NMC preference site 80 does not generate any reports and financial 
account infomnation is not accessible through this site. In an alternative embodiment, prior to gaining access to the 

50 NMC preference site 80, the NMC is required to provide payment infomnation in order for the host to charge the NMC 
for the notification service. In this embodiment, the NMC provides, e.g., credit card and billing infomnation to the host. 
The host establishes a desired method and time for payment, e.g. , flat monthly fee, fee based on number of alerts, fee 
based on type of alerts (see below). 

[0031 ] In a further alternative embodiment, the host provides the NMC with the same alerts that are provided to the 
55 MC. In this altemative embodiment, the host uses either pre-established lines of communication, such as ATM lines, 
credit authorization lines, settlement lines (e.g. . Automated Clearing House) and/or specifically negotiated and estab- 
lished lines of communication, In order to obtain the NMC's financial Infonmatlon from the NMC's financial institution. 
Referring to FIG. 1, the NMC's financial infonnation is obtained through external sources 28 and stored In the rates 



EP1 146 459A1 



and information database 30. For example, a customer with a single checking account at Chase Manhattan signs onto 
the notification system hosted by CITIBANK and requests that the notification system alert the customer via SMS 
instantaneously when the customer's checlcing account balance is below $1,000.00. In this alternative embodiment, 
the NMC is provided with some or all of the notification options that are available to the MCs. In order to provide this 

5 alert, CITIBANK cannot use its internal sources. Consequently, referring to FIG. 10, when the customer selects the 
"CONTINUE" button, the customer will be queried for all identifying infomiation necessary to complete the alert. In this 
example, the customer supplies information that identifies the customer and the customer's account to Chase Man- 
hattan so that Chase Manhattan can release the customer's infonmation to CITIBANK. This infomiation Includes, for 
example, the customer's CIN, the customer's checking account infomnation, including account number, as well as 

10 Chase Manhattan's identifying Information, such as bank routing number or bank identification number ("BIN**). Using 
this identifying infonnation, CITIBANK establishes a standing request to Chase Manhattan to send the customer's 
checking account to CITIBANK whenever there is a change In, for example, the amount in the customer's checking 
account. When the updated checking account information is received at CITIBANK, the updated checking account 
infonnation, e.g., balance, is compared to the customer's request and if the balance is below $1 ,000.00, the CITIBANK 

IS notification system formulates a notification message and sends the message to the customer using SMS. If the balance 
is at or above $1 ,000.00, no message is fonnulated and the notification system waits for the next update. 
[0032] As with the MCs and the NMCs login, the CSRs are also able to access the notification system through the 
Web site 12. A CSR selects the CSR login link 15 on Web site 12. CSR login link 15 links the CSR to login Web page 
71, wherein the CSR is prompted to enter identification infomiation, such as CSR Name 73 and CSR NUMBER 75, 

20 as shown in FIG. 11 . Unlike the login choices presented to the MCs and the NMCs in FIG(8). 3 and 6, the CSR is not 
offered a first-time login link. The CSR must already have been assigned the appropriate identifiers prior to entering 
the login Web page in order to successfully login to the notification system 10. 

[0033] Referring to FIG. 12, upon successful login, CSRs are linked to a CSR preference site 90, where the CSR is 
able to create customer requests 92 and set notification channel options 94 and notification time options 98 on behalf 

25 of the customers, e.g. . MCs and NMCs. CSRs enter the customer's Customer Identification Number (CIN) 96 in order 
to access previously entered customer infonnation files or to create new files under this CIN. By way of example, the 
content to be notified on may include, but Is not limited to infonnation relating to the MCs checking, savings and portfolio 
values, interest rates, stock quotes, credit care charges (e.g. , over a specified amount, made in a specified geographic 
region, made in a specific retail store) automatic bill payments ( e.g. , car loan, mortgage, school loans, telephone, 

30 utilities, insurance, and the like), ATM withdrawals, credit specials (e.g., special loans, low credit card rates) and other 
financial specials offered by the host. After making general notification selections via the CSR preference site 90, the 
CSR is linked to other Web pages (not shown) via the "CONTINUE" icon where they are able to provide more specific 
request infonnation (e.g. phone #, fax #, alert customer when home mortgage rates reach X%). 
[0034] - By way of example, in FIG. 13 a method of practicing the invention begins with a customer entering an initial 

35 Web site (e.g., CITIALERT^m Web site) maintained by the host (e.g., CITIBANKtm) (S1). The Web site prompts the 
customer to select the icon which reflects the customer's status as either a MC or a NMC (82). If the customer selects 
the NMC Icon, the NMC is linked to the NMC login Web page (S3). The NMC login Web page queries the NMC as to 
whether or not this is their first login attempt (84). If this is the NMCs first login attempt, the NMC selects the appropriate 
icon, is linked to the first-time login Web page, and provides the requisite infonnation (85). Assuming the NMC has 

40 logged in at some previous time, the NMC selects the repeat customer icon and enters the appropriate ID Name and 
PASSWORD (86). After logging in, the NMC is directed to the stateless NMC preference site where the NMC is prompt- 
ed to select message and notification information (87). 

[0035] If in response to (82) the customer selects the MC Icon, the MC is linked to the MC login Web page (88). The 
MC login Web page queries the MC as to whether or not this is their first login attempt (89). If this is the MCs first login 

^5 attempt, the MC selects the appropriate icon, is linked to the first-time login Web page, and provides the requisite 
infonnation (810). Assuming the MC has logged in at some previous time, the MC selects the repeat customer icon 
and enters the appropriate ID Name and PASSWORD (811). After logging in, the MC is directed to the MC preference 
site (e.g., CITIDIRECT® site) where the MC Is prompted to select message and notification infonnation (812). 
[0036] Within both the NMC preference site 80 and the MC preference site 70, respectively, the customers are prompt- 

50 ed to choose and provide information relating to a message they would like to receive and also to select the notification 
alert message gateway 40 through which they would like to be alerted of the message (813). This infonnation is saved 
by the notification system 10 within the host-handoff files 16, (814). The host-handoff files 16 are accessed by multiple 
servers (see FIG. 1) and data therefrom is compiled into specific request and notification files (815). The specific 
requests are compared to continuously Incoming information from Intemal and external sources (816). The notification 

55 system 1 0 ascertains If there is a match (817). If there is a match, the customer is notified according to the customer's 
request, through the customer's selected gateway (818). If there is no match, the request Is compared to the next bit 
of incoming infonnation (819), until the request is fulfilled. 

[0037] The notification system 10 described above is capable of alerting customers in multiple transaction areas. In 
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embodiments of the present invention, MCs enjoy a wider range of possible notification scenarios, due to thieir financial 
relationship with the host. For example, MCs may be alerted as to account balances, CD maturation, credit card pay- 
ment being due, a checic has bounced, foreign or domestic exchange has hit a target price, foreign exchange rates, 
domestic Interest rates, etc. Either the MC or a CSR would enter the appropriate preference cite and proceed to enter 

s the request. In an alternative embodiment, if the MC has a broker relationship with the host, an embodiment of the 
present invention contemplates a multiple alert scenario, wherein, for example, the MC requests notification when a 
particular stocl< hits a specified value. This is the first alert. The MC further instructs the host broker at the time of 
establishing the first alert, to buy X shares of the stock, using funds from a specified account, when the stock value 
reaches this specified value. The host broker sends a second alert notifying the MC that the transaction has been 

10 completed. Altematlvely, after sending the first alert, instead if purchasing the stock automatically, the host broker is 
instructed by the MC to wait for a reply message from the MC prior to purchasing the stock. Although more restricted 
in the types of alerts that they may receive in certain embodiments, NMCs may still be alerted regarding for example, 
interest rates and stock prices. 

[0038] In various embodiments of the present invention all of the customers of the notification system 1 0 create their 
IS own login IDs and PASSWORDS through a web application interface in order to access the notification system 10 via 
the Internet. Customer login IDs and PASSWORDS are subject to creation business rules and are checked for unique- 
ness. The web application login IDs are independent of any host ID such as host account numbers, or CINs in the case 
of MCs. The PASSWORDS are kept in encrypted format. In the case of NMCs, the ID and PASSWORD may only grant 
them limited access to the notification system 1 0. In alternative embodiments, the MCs may have access to other levels 
20 or databases within the notification system due to their membership status. In order to access these databases, in 
addition to their self-created IDs and PASSWORDS, MCs are prompted to enter additional identifying infomnation such 
as, account numbers or CINs. 

[0039] In various preferred embodiments of the present invention, once the customers have created IDs and PASS- 
WORDS, the notification system 10 offers multiple avenues for alerting or notifying the customers of financial oppor- 

25 tunities to which they might wish to avail themselves. Referred to herein as alert message gateways 40, these Include 
but are not limited to electronic mail ("E-mail") 42, mobile phone text messaging, e^, Global System for Mobile Com- 
munications Service ("GSM") 50, facsimile ("Fax") 54, extensible mark-up language ("XML") 52, hypertext mark-up 
language ("HTML") 44, pager service 46, and short message service (*'SMS'') 56. Additionally, personal contact meth- 
ods may also be chosen, such as person-to-person calls with CSRs 48. In the event that a particular notification gateway 

30 40 is not specifically selected, an embodiment of the present invention provides a default notification gateway, for 
example, the customer's e-mail address. In this embodiment, the e-mail address of the customer would be a required 
field that must be completed prior to enrollment into the notification system. 

[0040] In various embodiments of the present invention, customers access the notification system 10 for any of a 
variety of reasons. Customers may choose to access the notification system 10 In order to add new or updated infor- 
ms mation to one or more of the available databases. In particular, customers may wish to choose or change their prefer- 
ences for when and how they wish to be notified of transaction opportunities. Further, customer's may wish to check 
a log or report of the most recent notifications that they have received. For example, an embodiment of the present 
invention allows customers to check a report containing the last X (X = 1 , 2, 3....n) notifications of which the customer 
was alerted via their chosen notification gateway 40. Further as discussed with reference to FIG. 6(b), the report may 
40 contain a more detailed account of the substance of the notification for the customer to review prior to acting or not 
acting based on the information contained in the notification. 

[0041] Embodiments of the present invention allow host personnel or CSRs to access the notification system 10, in 
addition to customers accessing the notification system. CSRs, including host telephone operators, are able to create 
or update customer records through, for example, a web application interface. These additions or updates may be 

45 added in response to a customer call, either after the call or simultaneous therewith. In an alternative embodiment, the 
CSR accesses the notification system 10 to enter customer record information that has been collected from other off- 
line sources, such as from customer paperwork that has been completed by the customer for host service enrollment, 
e.g. opening new accounts, applying for loans, etc. As previously discussed, the CSR's also have IDs and PASS- 
WORDS to ensure the security of the customer records. Further, the embodiments of the present Invention contemplate 

50 that the CSR web application interface be only available to CSRs. 

[0042] In addition to adding or updating customer records directly into the Web site, an alternative embodiment 
enables the CSRs to access particular feeder databases or servers which are not part of the immediate Web site 
databases/servers and enter data thereto for later addition to the Web site databases/servers. In this embodiment, the 
files from the off-site databases or servers (hereafter "feeder servers") are fed into the Web site databases/servers in 

55 response to an established execution program. These feeder servers are as numerous as is necessary in order to 
efficiently and accurately supply customer and other relevant infomnation to the Web site databases/servers. The pos- 
sible configurations are too numerous to mention but one skilled in the art will recognize the many variations which 
flow from the following embodiments. 
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[00431 The alert message text database 26 contains the notification requests based on the specified customer pref- 
Ss. in addition to the'substantive requests (e.g.. notify me when each share of Microsoft® .s $150)jch request 
record stored in the alert message text database 26 indicates the customer's preferred f f^^ f.^^^^^^ 
me with the notification at the following number (zzz-zzz-zzzz). This database ut.l«es '"'^f" JJ*^^^^^^^ 
the customer preference databases 24. The fomiatted requests held In the alert message text database 26 are ac 
cessed and searched during the running of the execution program (e.g.. CITIALERTtm software program), using .n- 
fomiation from the host handoff flies as well as the rate and infomiation databases. If an alert condition has been 
saS based on the up-to-date infomiation. the alert message text database 26 initiates the procedure for not.fy.ng 
the ciTstomer that the request has been met. The following tables represent various schema followed for access.ng 
and utilizina infomnation from the alert message text database 26. _ 
r00441 The feeder servers, as well as the Web site databases/servers may be separated, depending design 
parameters and the type of notification scenarios envisioned, into various types of categories. For example the Web 
rdlbases/sen^ers might Include as shown in FIG. 1. customer preference database 24.;at- -d .n^^^ 
database 30. alert message text database 26. access database (not shown), and f.nally host-handoff hies 16. These 

lists of cateqonr types are not meant to be limiting, they are merely exemplary. 

0045 In an embodiment of the present Invention, the customer preference database 24 contains .nfonT.at,on about 
hecustomer. customer preference infomiation. CSR infomiation. notification method infomiation. rates and -nformation 
darincludir^g prompt and response data, and display group infomiation. Each type of ^fomiation .s represer^ted in 
Shematables such as those plted and descrtbedfurtherwlth 

TeUorth below are merely exemplaiy and may include more or less infomiation as detemiined by one skilled .n the art 
for the type of notification system that is envisioned. ^ Hotn 

;046] in certain embodiments of the present invention, the customer prefererice database 24 contains m^^^^^^^ 
tables for storing and correctly logging in required data Into the requisite datafields. In these certain embodiments, the 
c' sfome prXence database 2Ais accessed and infomiation is entered thereto by multiple entries, for muttiple pur- 
poJ^The Sng tables provide exemplary data schema formats for data storage within the customer preference 

?004??"Referring to TABLE 1 . the exemplary "Customer from Customer Preferences Database" table includes for 
example an unique customer identifier used internally by the host, customer name, contact .n omiat.on (e^. phone 
f^Zrlberis) e mail address, GSM or other mobile phone text messaging numbers). CSR ID. custorner type/host 
amiiaSon MC or NMC). password(s), and login ID. The customer preference database retains a p^swc^ds 
Sic uding cier passwords, in encrypted fomiat. TABLE 1 contains a default notification method da a field which 
rrnks a cu tome,s preference for notLtion methods, e^ e-mall first. GSM second, f^^'-^' ^^J"!-^^^^^^^^ 
data fields containing: the date for the last time a modification was made to a particular customer's notrfication record, 
an ^«^^aLn C o?indica« whether a message is to be sent for a particular notification subscription or not ej. 
Is^Ss resSg from a parScular notification subscription are held In queue; and an authentication cookie generated 
each time a customer retrieves their record to be updated. 



Customer from Customer Preference Database 


Name 


Type 


Length 


Description 


Customerld 


Int 


4 


Internally generated Unique identifier of the record. 
(Primary Icey) 


CustomerType 


Char 


1 


"C" for CITIDIRECT or CITIGOLD customers 
"0" for non-Host customers 


Loginld 


Char 


22 


User created login ID for non-CITIDIRECT customers. 
Customer Identification Number (CIN) for CITIDIRECT 
customers. 


Password 


Char 


10 


User created password for non-CITIDlRECT customers. 
Not used for CITIDIRECT customers 


Name 


Char 


60 


Customer first name, last name and title 


Email 


Char 


50 


E-mail address to receive alerts 
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TABLE 1 (continued) 



Customer from Customer Preference Database 


Name 


Type 


Length 


Description 


GSMNumber 


Char 


20 


GSM phone number to receive alerts 


FaxNumber 


Char 


20 


Fax number to receive alerts 


DefaultNotificationMethod 


Char 


1 


"V'for E-mail 
"2" for GSM 
"3" for FAX 


LastModifiedDate 


Time Stamp 


8 


Date when the Customer record was last updated. 


CSRId 


Int 


4 


Reference to CSRs table. Customer's Account 
representative. 


DayPhone 


Char 


20 


Customer's day time phone number 


EvenlngPhone 


Char 


20 


Customer's evening time phone number 


Activation Flag 


Char 


1 


"Y" means alert messages will be generated for this 
subscription and Customer's will see this prompt on their 
screen. "N" means alert messages will not be generated 
for this subscription and Customer's will not see this 
prompt on their screen. This flag is used when the 
customer does not want to receive alerts yet he/she does 
not want to clear the current alert settings. 


AuthCookie 


Char 


40 


It's an application cookie generated each time customer 
fetches his/her record for update. This value Is compared 
upon fonn submit. 



[0048] Referring to TABLE 2, the exemplary "Customer Request from Customer Preferences Database" table in- 
cludes: customer ID (described above); identification of the processor type, e^., rates and Information or host type; 
reference ID, e.g., the alert to which the customer has subscribed which is dependent upon processor type; threshold 
flag; threshold value; notification method; notification limit; last notification date; and CIN for MCs, e.g., used to access 
MC inlfomiatlon from host database. Customer requests are separated through this table according to the whether the 
customer's request requires that the internal host databases be accessed to fulfill the request, e.g., for various MC 
requests involving an MCs account(s) with the host, or requires that extemal databases be accessed to fulfill the 
request. This table Includes a threshold flag data field for indicating whether a particular updated value Is the same, 
greater, or lesser than a customer indicated threshold value (e.g. , interest rates, stock quotes). The notification limit 
data field holds an Indicator for how often or how many times a customer chooses to be notified of the same alert, e^ 
g., no limit, no alert, a specified number. 



TABLE 2 





Customer Requests from Customer Preference Database 


45 


Name 


Type 


Length 


Description 




Customerld 


Int 


4 


Reference to a Customer record. 
(Primary key part 1 of 3) 


50 


ProcessorType 


Char 


1 


"1" for Rates and Info type 
"2" for Host type 

This field Is required since the public lnfomr)ation and data 
obtained from the host are in different database. 
(Primary key part 2 of 3) 



55 
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Customer Requests from Customer Preference Database 


Name 


Type 


Length 


Description 


Referenceld 


Int 


4 


This field is used to identify which alert the customer is 
subscribing to. Reference to a RatesAndlnforPrompts record 
when ProcessorType is "1" Reference to a HostlnfoPrompts 
record when ProcessorType is "2" (Primary key part 3 of 3) 


ThresholdFlag 


Char 


1 


For Rate type alerts it indicates the comparison mode of the 
current rate and the customer indicated threshold value. 
"0" for any change 

"1" if current rate is greater then threshold value 
"2" if current rate is less then threshold value 


ThresholdValue 


Float 


8 


For Rate type alerts It Is the customer target value 


NotificationMethod 


Char 


1 


The notification method for this alert. 

"0" use customer's default notification method 

"V'for E-mail 

"2" for GSM 

"3" for FAX 


NotificationLimit 


Int 


4 


Number of times to be notified, "-r for No limit. "O" for no alerts 
will be generated 

A Positive number will generate an alert and the number will be 
decremented automatically. 


LastNotificationDate 


Time Stamp 


8 


Last time an alert was generated. 

-rule. fSAiH ie iieoH h\i thp Alert Messaoe Generator's to avoid 

sending duplicate messages. 


CIN 


Char 


22 


Customer Identification Number (CIN) for CITIDIRECT 
customers. This field is duplicated here for perfomnance 
optimization (In Ideal DB design this field should be obtained from 
Customers table Login field. 



r00491 Referring to TABLE 3. the exemplary "Customer Service Representative from Customer Preferences Data, 
base" tabte InTd^^^^^ ID which is an internally generated identifier unique to each CSR. name, phone number, e- 
mail, and a CSR manager's ID. which Is the identifier for the CSR's manager. 

TABLE 3 



Customer Service Representative from Customer Preference Database 



Name 


Type 


Length 


Description 


CSRld 


Int 


4 


Internally generated Unique identifier of the record. (Primary key) 


Name 


Char 


60 


Customer Representative first name, last name and title 


Email 


Char 


50 


E-mail address to receive copy of the alerts sent to the their customers. 


Phone 


Char 


20 


Phone number 


Managerld 


Int 


4 


1 Reference to a another CSR record which represents this CSR's manager 



[0050] Referring to TABLE 4. the exemplary -Notification Methods from Customer Prefejnces^^^^^^ tabje in- 
cludes the data fields for the type of notification methods that are available and the specifications for the text that 
appears for the heading of each notification method. 
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TABLE 4 



Notification Methods from Customer Preference Database 


Name 


Type 


Length 


Description 


NotificationMethod 


Char 


1 


"rfor E-mail 
"2"forGSI\/l 
"3" for FAX 


Heading 


Char 


20 


The textual phrase appearing on different screens (Web sites). 



[0051 ] Referring to TABLE 5, the exemplary "Rates and Infomiation Prompts from Customer Preferences Database" 
table includes data fields for: an unique interna! identifier for a particular rates and Infonnation prompt; a display group 
identifier; the display order; rates and Infonnation types; prompt text; CSR notification; activation flag; start date; ex- 
75 piration date; cun^ent rate; last update date; and automatic feed Identifier. 

[0052] The display group identifier identifies the particular group of prompts to which this particular prompt belongs. 
Exemplary display groups include, for example, auto loans, Certificate of Deposit ("CD") rates, mortgage rates, stock 
quotes, credit card rates, etc. The display order data field determines the order in which a particular prompt appears 
on the customer's notification screen. The rates and infonnation type data field reflects whether the prompt is directed 
20 toward product infomiation only or product infonnation with the associated rates. For example, product Infomiation 
only is a list of available mortgage loans such as 30-year fixed, 30-year variable, 15-year fixed, and 15-year variable, 
while product information with associated rates would include the types of mortgage loans plus the current interest 
rates for each. The prompt data field dictates the fonmat, e^, length, type of the notification textual phrase. The CSR 
notification data field dictates whether or not the customer chooses to have a CSR be copied on an alert. CSR notifi- 
es cation may be desirable, for example, where the customer desires that he be notified of alerts by a CSR directly. The 
start, expiration, and last update date data fields indicate the date on which the notification system should begin gen- 
erating appropriate alert messages, the date after which the system will no longer generate alert messages, and the 
date on which the cun'ent rate and Info prompt record was updated, respectfully. The current rate data field contains 
the current rate, e.g. . interest rate, against which a customer's threshold rate Is compared. Finally, the auto feed identifier 
30 data field is used by the feeder applications (discussed above) to Identify matching records during the process of 
importing rates and infonnation from sources. 



TABLE 5 



Rates and Infomiation Prompts from Customer Preference Database 


Name 


Type 


Length 


Description 


RatesAndlnfoPromptId 


Int 


4 


Internally generated Unique Identifier of the record. (Primary 
key) 


DisplayGroupId 


Int 


4 


Reference to DisplayGroups record which represents this 
Product Prompt grouping such as "Auto loans" or "30 day CD 
rates'" 


DisplayOrder 


Int 


4 


The order in which this prompt will appear on the Customer's 
screen within the DisplayGroup. 


RatesAndlnfoType 


Char 


1 


"1" for Product Infonnation only types 

"R" for Product information with associated rate 


Prompt 


Char 


100 


The textual phrase appearing on the different screen (Web 
sites) describing the alert. 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the customer then a 
copy will also be sent to the customer's CSR. 
"N" means do not send a copy to CSR. 



55 
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TABLES (continued) 





Rates and Information Prompts from Customer Preference Database 




Name 


Type 


Length 


Description 


5 
10 


Activation Flag 


Char 


1 


"Y" means alert messages will be generated for this 
subscription and Customer's will see this prompt on their 
screen. 

"N** means alert messages will not be generated for this 
subscription and Customer's will not see this prompt on their 
screen. 

This flag is used when the prompt is under construction or it 
is in the approval phrase. 


15 


StartDate 


Time Stamp 


8 


The date from which the system will generate alert messages. 
This field has no effect on Customer screens, which means 
that if the Activation Flag is "Y" then this prompt will appear 
on the Customer screen regardless of the StartDate field 
value. 


20 


ExplrationDate 


Time Stamp 


8 


The date after which the system will not generate alert 
messages. This field has no effect on Customer screens, 
wnicn means inat it tne Activaiionriag is y men mis prompi 
will appear on the Customer screen regardless of the 
ExplrationDate field value. 


25 


CurrentRate 


Float 


t% 
o 


The current rate to which Customer threshold targets are 
compared against. This field is valid only if the 
RatesAndlnfoType is "R". 


30 


LastUpdateDate 


Time Stamp 


8 


Last time this record or its corresponding response was 
updated. This field is used by the Alert Message generator's 
to avoid sending duplicate messages. 




Auto Feed Id 


Char 


10 


This field Is used by Feeder applications to identify matching 

records during Import process. 



35 [0053] Referring to TABLE 6, the exemplary "Rates and Information Responses from Customer Preference Data- 
base" table includes data fields for: an unique internal Identifier for a particular rates and infomriatlon response; the 
corresponding unique internal identifier for the particular rates and infomnation prompt; notification method; subject; 
response detail; and activation flag. 

[0054] The "Rates and Infomnatlon Responses from Customer Preference Database" details the corresponding re- 
40 sponse infomriation for the "Rates and Infomnatlon Prompts from Customer Preference Database." Consequently, the 
responses are assigned an identifier that is linked to the prompt identifier representing the prompt to which it is re- 
sponding. The subject data field dictates the textual phrase that appears in the response message heading, e.g.. such 
as the subject line in a standard e-mail message. The response detail data field dictates the textual phrase that appears 
in the body of the response message, e.g., such as the body of a standard e-mail message. 

45 



TABLE 6 



Rates and Information Responses from Customer Preference Database 


Name 


Type 


Length 


Description 


RatesAndlnfoResponseld 


Int 


4 


Internally generated Unique identifier of the record. (Primary 
key) 


RatesAndlnfoPromptid 


Int 


4 


Reference to a RateAndlnfoPrompts record which 
represents the prompt (question) to this response. 



55 
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TABLE 6 (continued) 



Rates and Infomriation Responses fronfi Customer Preference Database 


Name 


TVpe 


Length 


Description 


NotificationMethod 


Char 


1 


"0" for default response for all methods 
"r for E-mail 
"2" for GSM 
-3" for FAX 


Subject 


Char 


100 


The textual phrase appearing on the Response message 
heading. This is the same as standard E-mail subject text. 


ResponseDetait 


Var Char 


1024 


The textual phrase appearing on the Response message 
body. This is the same as standard E-mail body text. 


Activation Flag 


Char 


1 


"Y" means this response is ready to be sent to customers. 
"N" means this response is not ready to be sent to 
customers.. 

This flag is used when the response is under construction or 
it is in the approval phrase. 



[0055] Referring to TABLE 7, the exemplary "Display Groups from Customer Preference Database" table includes 
data fields for: a display group identifier; heading; source database; and the display order. The source database indi- 
cates the database which stores the display groups, e^, the customer preference database. 

TABLE 7 



Display Groups from Customer Preference Database 


Name 


Type 


Length 


Description 


DisplayGroupId 


Int 


4 


Internally generated Unique identifier of the record. (Primary key) 


Heading 


Char 


80 


The textual phrase appearing on different screens (Web sites). This field 
represents the Product grouping such as "Auto loans" or "30 day CD 
rates". 


SourceDB 


Int 


4 


"1" for Customer Preference Database 


DisplayOrder 


Int 


4 


The order in which this product grouping will appear on the Customer's 
screen. 



[0056] In an embodiment of the present invention, the rates and infomriation database 30 contains promotional con- 
tent such as current rates and upcoming specials. This database keeps generic notification options available to all 
customers. This database can also be used to broadcast critical messages to selected customers. For example, if a 
customer has indicated a specific price at which the customer wishes to purchase a specified amount of stock or has 
requested notification in the event of a particular amount of variation in a foreign exchange rate, the rates and infor- 
mation database contains this type of information. 

[0057] In an embodiment of the present invention, the alert message text database 26 is used to keep the content 
of the text of the alert messages (provided by the host handoff files database 16) in an efficient fornnat. Only the latest 
handoff file content is retained in the alert message text database 26. 

[0058] Referring to TABLE 8. the exemplary "Host Infomiation Prompts from Alert Message Text Database" table 
includes data fields for: an unique intemal identifier for a particular host infomriation prompt; a display group identifier; 
the display order; prompt text; CSR notification; activation flag; start date; expiration date; message code; last update 
date; and automatic feed identifier. 

[0059] The majority of the data fields from TABLE 8 are described with reference to at least TABLE 5. Additionally, 
the message code Is an action code that is set by the host and represents the host identified event which the customer 
has selected for alert purposes. This message code is used by the alert message generator to map host event records 
to host infomiation prompt records. 
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Host Information Prompts from Alert Message Text Database 


Name 


TVpe 


Length 


Description 


HostlnfoPromptld 


Int 


4 


Intemally generated Unique identifier of the record. (Primary key) 




Int 


4 


Reference to DisplayGroups record which represents this Product 
Prompt grouping such as "Checldng accounts" or "Money Market 
Accounts" 


uispiayL^raer 


Int 


4 


The order in which this prompt will appear on the Customer's 
screen within the DisplayGroup. 


Prompt 


Char 


100 


The textual phrase appearing on the different screen (Web sites) 
describing the alert. 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the customer then a copy 
will also be sent to the customer's CSR. 
"N" means do not send a copy to CSR 


ActivationFlag 


Char 


1 


"Y" means alert messages will be generated for this subscnption 
and Customer's will see this prompt on their screen. 
"N" means alert messages will not be generated for this 
subscription and Customer's will not see this prompt on their 

screen. 

This flag is used when the prompt is under construction or it is in 
the approval phrase. 


StartDate 


Time Stamp 


8 


The date from which the system will generate alert messages. This 

1-1 i_ ^ts^^*- f^i tt>fr\rr%Ar er^rAAnC \A/hich mfiSnS that If tlie 

field has no efiecl on uusiomer screerib, wiuun incano n n.w 
ActivationFlag is "Y" then this prompt will appear on the Customer 
screen regardless of the StartDate field value. 


ExplratlonDate 


Time Stamp 


8 


The date after which the system will not generate alert messages. 

-1-U2-. rk/> ^Har^f #^n Oifctnmpr («cr66ns which means that If 
This tieici nas no eneci on ouoiwiiici out ecu©, wwinvn mw^^iiw 

the ActivationFlag is "Y" then this prompt wiil appear on the 

Customer screen regardiess of the ExpirationDate field value. 


MessageCode 


Float 


8 


-ri»^ »^4^i^n ^f\ria eat Vwi tho Hhqi which fsDresents this event. For 
The action cooe sex oy ine nuoi, wnion i^i-noooiina unw 

example "11111" means overdraft. The Message code is used by 

the host alert message generator to map a HostEvent record to 

HostlnfoPrompt record. 


LastUpdateDate 


Time Stamp 


8 


Last time this record or its corresponding response was updated. 
This field is used by the Alert Message generator's to avoid sending 
duplicate messages. 


AutoFeedId 


Char 


10 


This field Is used by Feeder applications to Identify matching 
records during Import process. 



[00601 Referring to TABLE 9. the exemplary "Host Infomiation Responses from Alert Message Text Database tabl^ 
ncludes data fields for: an unique Internal identifier for a particular rates and infomiafon response; ^^^one^^^^^^^ 
unique internal identifier for the particular rates and information prompt; notification method; subject; response detail, 
and activation flag. The description of these data fields is found with reference to TABLE 6. 



Host Information Responses from Alert Message Text Database 


Name 


Type 


Length 


Description 


HostlnfoResponseld 


Int 


4 


Intemally generated Unique identifier of the record. (Primary key) 
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TABLE 9 (continued) 





Host Information Responses from Alert Message Text Database 




Name 


Type 


Length 


Description 


5 


HostlnfoPromptId 


lot 


4 


Reference to a HostlnfoPrompts record which represents the prompt 
(question) to this response. 


10 


NotiflcationMethod 


Char 


1 


"0" for default response for all methods 
-rfor E-mail 
"2" for GSM 

& iwi wiwivi 

"3" for FAX 




Subject 


Char 


100 


The textual phrase appearing on the Response message heading. This 
is the same as standard E-mail subject text. 


15 


ResponseDetail 


Char 


1024 


The textual phrase appearing on the Response message body. This Is 
the same as standard E-mail body text. 


20 


Activation Flag 


Char 


1 


"Y** means this response is ready to be sent to customers. 
"N" means this response is not ready to be sent to customers.. 
This flag is used when the response is under construction or it is In the 
approval phrase: 



[0061] Referring to TABLE 1 0, the exemplary "Host Event From Alert Message Text Database" table Includes data 
fields for: an unique identifier for Identifying a host event; account number; product type code; sub product code; 
currency code; CIN; message code; current value; as of date; last update date; and notes. 

[0062] In addition to previously defined data fields, further data fields defined through TABLE 10 Include identifiers 
for identifying a customer through the customer's relationship with the host. For example, account number, product 
type, sub product type, and currency code represent four (4) data fields that link a customer to the host. In a particular 
exemplary embodiment, a customer has a checking account, e.g. , account number, with the host as well as a car loan, 
e.g. , product type, wherein the car loan Is a 5 year loan at an 8.0% fixed interest rate, e^g., sub product type, calculated 
in U.S. dollars, e.g. . cun^ency. The notes and as of date data fields are for Infonnation which is only merged with the 
response detail or the message text when messages are sent to the customers. For example, the notes data field is 
used to send account specific Infomiation such as cun^ent balance. 



TABLE 10 



Host Event From Alert Message Text Database 


Name 


Type 


Length 


Description 


HostEventId 


Int 


4 


Intemally generated Unique identifier of the record. (Primary 
key) 


AccountNumber 


Char 


22 


Account number. Part 1 of 4 to uniquely Identify a relationship 
with Host. 


ProductTypeCode 


Char 


3 


Product type. Part 2 of 4 to uniquely identify a relationship with 
Host. 


SubProductTypeCode 


Char 


2 


Sub product type. Part 3 of 4 to uniquely Identify a relationship 
with Host 


CurrencyCode 


Char 


3 


Currency Code. Part 4 of 4 to uniquely identify a relationship 
with Host 



55 
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Host Event From Alert Message Text Database 


Name 


Type 


Length 


Description 


CIN 


Char 


22 


Customer Identification Number. This field is used to identify 
the specific Customer request record. 


MessaaeCode 


Float 


8 


The action code set by the Host, which represents this event. 
For example "11111" means overdraft. The Message code is 
used by the host alert message generator to map a HostEvent 
record to HostlnfoPrompt record. 


CurrentValue 


Float 


8 


The current value to which Customer threshold targets are 
compared against. For example if a customer wants to be 
notified if his/her balance is below certain amount. 


Aer^fr^ato 
MSvJilJmo 


Time Stamp 


8 


This field is for infomnation only which will be merged with the 
Response Detail (body) when messages are sent to the 
customers. 


LastUpdateDate 


Time Stamp 


8 


Last time this record or its conresponding response was 
updated. 

Thie fioiH ic iiQed bv the Alert Message generator's to avoid 
sending duplicate messages. 


Notes 


Char 


120 


The textual phrase, which will be merged with the Response 
Detail (body) when messages are sent to the customers. This 
field can be used to send account specific data such as current 
balances. 



10 



IS 



20 



25 



30 



r00631 Referring to TABLE 11 . the exemplanr "Display Groups from Alert Message Text Database tabte includes 
?aSlds tor: a display group identifier; heading: source database; and the display order. The source database md.- 
cates the database which stores the display groups, e^. the host handoff database. 



Display Groups from Alert Message Text Database 


Name 


Type 


Length 


Description 


DisplayGroupId 


Int 


4 


Internally generated Unique identifier of the record. (Pnmary key) 


Heading 


Char 


80 


The textual phrase appearing on different screens (Web sites). This field 
represents the Product grouping such as "Checking accounts" or "CDs". 


SourceDB 


Int 


4 


"2" for Host handoff database 


DisplayOrder 


Int 


4 


The order in which this product grouping will appear on the Customer's 
screen. 



35 



40 



45 



50 



mo641 Referrina to TABLE 12 the exemplary "Alert Messages from Alert Message Text Database" table includes 
Sids ^^^^^^ customer ID; customer type; notification method; processor type; reference 

iriontifipr rrpate date* sent date; subject; response detail; and CSR notification. 

msT'ZVnZeZ^^^^ un quely identified to the database through an Identifier. In addition to previousV 
deffned date fS TnTZ toiulate specific alert messages the requesting customer is identified through a cus^ 
toTeMD te Itom^^^^^^^ as an MC or NMC is identified, the notiffcation method is identified the Processor ^pe 
IsTdenSed^^^^^^^^^^^^ ID is used to identify which alert the customer has selected. Further, the create and sent 

dates Identify when the alert message was created and sent, respectively. 



55 
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TABLE 12 





Alert Messages from Alert Message Text Database 


D 


Name 


Type 


Length 


Description 




AlertMessageld 


Int 


4 


Internally generated Unique identifier of the record. (Primary l<ey) 




Customerld 


Int 


4 


Reference to a Customer record. 


10 


CustomerType 


Char 


1 


C for CITIDIRECT or CITIGOLD customers 0 for non-Host 
customers 


15 


NotiflcationMethod 


Char 


1 


The notification method for this alert. 
"0" use customer's default notification method 
r for E-mail 
"2" for GSM 
"3" for FAX 


20 


ProcessorType 


Char 


1 


"1" for Rates and Info type 
2 for Host type 

This field is required since the public infomnation and data obtained 
from the host are In different database. 


25 


Referenceld 


Int 


4 


This field is used to identify which alert the customer is subscribing 
to. Reference to a RatesAndlnforPrompts record when 
ProcessorType is "r Reference toaHostlnfoPrompts record when 
ProcessorType is "2" 


Createdate 


Time Stamp 


8 


Timestamp when this record is created 




SentDate 


Time Stamp 


8 


Timestamp when alert was sent 


30 


Subject 


Char 


100 


The textual phrase appearing on the Response message heading. 
This Is the same as standard E-mail subject text. 




ResponseDetail 


Var Char 


1024 


The textual phrase appearing on the Response message body. 
This is the same as standard E-mail body text. 


35 


NotifyCSR 


Char 


1 


"Y" means when a message is sent to the customer then a copy 
will also be sent to the customer's CSR. 
"N" means do not send a copy to CSR. 



[0066] In certain embodiments of the present invention, the access database is used to give database access to all 
other applications within the notification system. 

40 [0067] Referring to TABLE 1 3, the exemplary "Access from Access Database" table includes data fields for: an access 
ID; login ID; password; last changes date; connection string; and password change interval. The access database 
gives a requesting database/server with an appropriate access Identifier, the proper database connection string, da- 
tabase login ID . and password for the database that is sought to be accessed. The table also tracks password changes 
through the last changes date data field and contains the value for the time intervals at which the password is required 

45 to be changed for security reasons through the password change Interval data field. 



TABLE 13 



Access from Access Database 


Name 


Type 


Length 


Description 


Accessid 


Int 


4 


Internally generated Unique identifier of the record. 
(Primary key) 


Loginid 


Char 


20 


Database login name 
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TABLE 13 (continued) 



Access from Access Database 


Name 


Type 


Length 


Description 










LastChangedDate 


Time Stamp 


8 


Last time the Login password was changed 


ConnectionString 


Char 


120 


Database connections string 


PasswordChangeinterval 


Int 


4 


Number of days when a new password should be 
generated for this login 



[0068] In certain embodiments of the present invention, servers are either accessed or perfomn an accessing function 
in order to update one or more of the databases described above. In order to provide timely notifications to customers, 
it Is necessary to ascertain and synthesize the most up to date infomnation that is available. As was discussed previously, 
data may be collected from a variety of different sources and fed into a variety of different databases or files. The tenri 
"servers" is a generic terni utilized to describe any and all sources of data and infomnation which may be used to update 
the specific databases described above. These servers could be databases, servers, or direct data links, such as 
people, entering information In real-time or networks. 

[0069] The tables and descriptions set forth herein are merely meant to be exemplary embodiments of the present 
invention and are not intended to be limiting. One skilled in the art recognizes the many variations and embodiments 
which fall within the scope of the invention. 



Claims 

1 . A method for notifying a customer of at least one requested event comprising: 

providing the customer with access to a notification system, including, 

(1) detennining a status of the customer as a member customer or a non-member customer of an institution 

providing the notification system, 

(ii) generating access data for the customer, and 

(ill) prompting the customer for the access data; 

prompting the customer to select at least one requested event, wherein a member customer is provided with 
more event choices that a non-member customer; 

storing the customer's at least one requested event selection in a first database; 

prompting the customer to select at least one method of notification; 

storing the customer's at least one method of notification selection In the first database; 

prompting the customer to select at least one time for notification; 

storing the customer's at least one time for notification selection in the first database; 

receiving trigger data from at least a second database into the notifbation system that triggers the at least one 

requested event; 

fomiulating a notification message that includes infomiatlon about the at least one requested event; and 
sending the notification message to the customer via the customer's at least one method of notification at the 
customer's at least one time for notification. 

2. The method according to claim 1 , further comprising prompting the customer to select a method of payment for 
using the notification system. 

3. The method according to claim 2, wherein only non-member customers are prompted to select a method of payment 
for using the notification system. 

4. The method according to claim 1 , wherein at least the steps of providing the customer with access to a notification 
system, prompting the customer to select at least one requested event, prompting the customer to select at least 
one method of notification, and prompting the customer to select at least one time for notification are perfomned 
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by a customer service representative. 

5. The mettiod according to claim 1 , wlierein the second database contains customer-specific financial account in- 
fomiatlon. 

6. The method according to claim 5, wherein the customer is a non-member customer. 

7. A system for notifying a customer of at least one requested event comprising: 

means for providing the customer with access to a notification system, including, 

(i) means for detemiining a status of the customer as a member customer or a non-member customer of 

an institution providing the notification system, 

(li) means for generating access data for the customer, and 

(iii) means for prompting the customer for the access data; 

means for prompting the customer to select at least one requested event, wherein the member customer is 

provided with more event choices than the non-member customer; 

means for storing the customer's at least one requested event selection; 

means for prompting the customer to select at least one method of notification; 

means for storing the customer's at least one method of notification selection; 

means for prompting the customer to select at least one time for notification; 

means for storing the customer's at least one time for notification selection; 

means for receiving trigger data from at least a second database into the notification system that triggers the 
at least one requested event; 

means for fomnulating a notification message that includes infonnation about the at least one requested event; 
and 

means for sending the notification message to the customer via the customer's at least one method of notifi- 
cation at the customer's at least one time for notification. 

8. A system for notifying a customer of at least one requested event comprising: 

means for generating a customer's financial notification preferences which include, 

(i) at least one requested event, 

(ii) a customer's notification method preferences, and 
(ill) a customer's time for notification preferences; 

a database containing the customer's financial notification preferences; 

a database containing financial infonnation, wherein the financial Infonnation is collected from at least one 
internal source and at least one external source; 

a notification message generator for comparing the at least one requested event with the financial infonnation 
and generating a notification message when the financial information matches the at least one requested event; 
a notification gateway for sending the notification message to the customer according to the customer's noti- 
fication method preferences and time for notification preferences; and 

a database for generating a notification report at the customer's request, wherein the notification report includes 
at least data describing each notification message sent to the customer during a customer selected period of 
time. 

9. The system according to claim 8. wherein the at least one requested event is related to one of the following group 
consisting of a customer checking account, a customer savings account, a customer financial portfolio, a customer 
credit card, stock quotes, foreign exchange rates, interest rates, and loans. 

10. The system according to claim 8, wherein the customer's notification method preferences are selected from the 
following group consisting of electronic mail, hypertext mark-up language, pager, mobile phone text messaging, 
extensible mark-up language, facsimile, short message service, and telephone. 

11. The system according to claim 8, wherein the customer's notification time preferences are selected from the fol- 
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lowing group consisting of instantaneously, hourly, daily, weekly, and monthly. 

12. The system according to claim 8, wherein the at least one Internal source is a financial Institution that is hosting 
the system. 

5 

13. The system according to claim 8, wherein the at least one external source Is the Internet. 

1 4. The system according to claim 8, wherein the at least one external source is a financial institution that is not hosting 
the system. 

10 

15. The system according to claim 8, wherein customers are identified in the first database as being either member 
customers or non-member customers. 

16. The system according to claim 15, wherein the at least one external source Is a non-member customer's financial 
IS institution. 

17. The system according to claim 8, wherein the financial Infomnation includes customer's checl<ing account balance, 
customer's savings account balance, customer's portfolio value, stock quotes, and interest rates. 

20 1 8. The system according to claim 8. wherein the means for generating a customer's financial notification preferences 
includes a customer service representative. 

19. A method for formulating an alert message containing financial infomnation for a customer comprising: 

25 storing an alert prompt in a first database of a notification system hosted by a financial institution, wherein the 

alert prompt includes, 

(i) prompt details, 

(ii) a preferred method for notifying the customer of the alert message, and 
30 (iii) a preferred time for notifying the customer of the alert message; 

receiving financial information into a second database of the notification system, wherein the incoming financial 
infomnation is received into the second database from at least one outside source and at least one inside 
source, and further wherein the incoming financial infonnation received from the at least one inside source 
35 results from a change in at least one customer account maintained by the host financial institution; 

comparing the Incoming financial information with the prompt details of the alert prompt in the first database; 
and 

notifying the customer through the preferred method at the preferred time through an alert message when the 
prompt details match the Incoming financial infomnation. 

40 

20. The system according to claim 19, wherein the at least one internal source is a financial institution that is hosting 
the system. 

21. The system according to claim 19, wherein the at least one external source is the Internet. 

45 

22. The system according to claim 19, wherein the at least one external source is a financial Institution that is not 
hosting the system. 

23. A method for notifying a customer of at least one requested event comprising: 

50 

providing the customer with access to a notification system, including, 

(i) detemiining a status of the customer as a member customer or a non-member customer of a host 
institution providing the notification system, 
55 (ii) generating access data for the customer, and 

(iii) prompting the customer for the access data; 



prompting the customer to select at least one requested event, wherein the member customer Is provided with 
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more event choices than the non-member customer; 
prompting the customer to select at least one method of notification; 
prompting the customer to select at least one time for notification; 
fomriulatlng an alert prompt wherein the alert prompt Includes, 

5 

(Iv) the at least one requested event, 

(v) the customer's at least one method of notification, and 

(vi) the customer's at least one time for notification; 

storing the alert prompt in a first database of the notification system; 

receiving financial inf onmatlon Into a second database of the notification system, wherein the incoming financial 
infomnation Is received into the second database from at least one outside source and at least one inside 
source, and further wherein the Incoming financial information received from the at least one Inside source 
results from a change in at least one customer account maintained by the host institution; 
comparing the incoming financial infonnation with the at least one requested event of the alert prompt in the 
first database; and 

sending a notification message to the customer via the customer's at least one method of notification at the 
customer's at least one time for notification when the at least one requested event matches the incoming 
financial infonnation. 

20 



25 



30 



35 



40 



45 
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